Gh-Ost 在线DDL变更工具
背景
我们知道，MySQL 5.7以前的DLL采用的是：
新建临时表–>修改临时表结构–>然后导入数据–>drop原表–>重命名临时表为原表
MySQL 8.0仅支持加字段秒级完成，其他变更如添加索引，修改字段等仍是上述方式。比较经典的通用方案是Percona 公司开源的pt-osc 工具解决导致锁表的操作，还有一款github基于go语言开发的gh-ost。gh-ost拥有众多特性，比如 轻量级，可暂停, 可动态控制, 可审计, 可测试, 等等 ，我们可以通过操作特定的文件对正在执行的gh-ost命令进行动态调整 。
开源地址：
https://github.com/github/gh-ost
说明：
本文使用的gh-ost版本：v1.1.0
gh-ost 介绍
gh-ost 作为一个伪装的备库，可以从主库 / 备库上拉取 binlog，过滤之后重新应用到主库上去，相当于主库上的增量操作通过 binlog 又应用回主库本身，不过是应用在幽灵表上。
其大致的工作过程:
1 gh-ost 首先连接到主库上，根据 alter 语句创建幽灵表，
2 然后作为一个备库连接到其中一个真正的备库或者主库上 (根据具体的参数来定)，一边在主库上拷贝已有的数据到幽灵表，一边从备库上拉取增量数据的 binlog，然后不断的把 binlog 应用回主库。
3 等待全部数据同步完成，进行 cut-over 幽灵表和原表切换。图中 cut-over 是最后一步，锁住主库的源表，等待 binlog 应用完毕，然后替换 gh-ost 表为源表。gh-ost 在执行中，会在原本的 binlog event 里面增加以下 hint 和心跳包，用来控制整个流程的进度，检测状态等。
当然 gh-ost 也会做很多前置的校验检查，比如 binlog_format ，表的主键和唯一键，是否有外键等等
这种架构带来诸多好处，例如：
- 整个流程异步执行，对于源表的增量数据操作没有额外的开销，高峰期变更业务对性能影响小。
- 降低写压力，触发器操作都在一个事务内，gh-ost 应用 binlog 是另外一个连接在做。
- 可停止，binlog 有位点记录，如果变更过程发现主库性能受影响，可以立刻停止拉binlog，停止应用 binlog，稳定之后继续应用。
- 可测试，gh-ost 提供了测试功能，可以连接到一个备库上直接做 Online DDL，在备库上观察变更结果是否正确，再对主库操作，心里更有底。
- 并行操作，对于 gh-ost 来说就是多个对主库的连接。
gh-ost 操作模式
a. 连接到从库，在主库做迁移这是 gh-ost 默认的工作方式。gh-ost 将会检查从库状态，找到集群结构中的主库并连接，接下来进行迁移操作:
- 行数据在主库上读写
- 读取从库的二进制日志，将变更应用到主库
- 在从库收集表格式，字段&索引，行数等信息
- 在从库上读取内部的变更事件（如心跳事件）
- 在主库切换表
如果你的主库的日志格式是 SBR，工具也可以正常工作。但从库必须启用二级制日志 ( log_bin, log_slave_updates) 并且设置 binlog_format=ROW 。
b. 连接到主库
直接连接到主库构造 slave，在主库上进行 copy 数据和应用 binlog，通过指定 –allow-on-master 参数即可。当然主库的 binlog 模式必须是 row 模式。
c. 在从库迁移 / 测试该模式会在从库执行迁移操作。gh-ost 会简单的连接到主库，此后所有的操作都在从库执行，不会对主库进行任何的改动。整个操作过程中，gh-ost 将控制速度保证从库可以及时的进行数据同步
–migrate-on-replica 表示 gh-ost 会直接在从库上进行迁移操作。即使在复制运行阶段也可以进行表的切换操作。
–test-on-replica 表示 迁移操作只是为了测试在切换之前复制会停止，然后会进行切换操作，然后在切换回来，你的原始表最终还是原始表。两个表都会保存下来，复制操作是停止的。你可以对这两个表进行一致性检查等测试操作。
参数说明
-allow-master-master: 是否允许gh-ost运行在双主复制架构中，一般与-assume-master-host参数一起使用
-allow-nullable-unique-key: 允许gh-ost在数据迁移依赖的唯一键可以为NULL，默认为不允许为NULL的唯一键。如果数据迁移(migrate)依赖的唯一键允许NULL值，则可能造成数据不正确，请谨慎使用。
-allow-on-master: 允许gh-ost直接运行在主库上。默认gh-ost连接的从库。
-alter string:DDL语句
-assume-master-host string:为gh-ost指定一个主库，格式为”ip:port”或者”hostname:port”。在这主主架构里比较有用，或则在gh-ost发现不到主的时候有用。
-assume-rbr:确认gh-ost连接的数据库实例的binlog_format=ROW的情况下，可以指定-assume-rbr，这样可以禁止从库上运行stop slave,start slave,执行gh-ost用户也不需要SUPER权限。
-chunk-size int:在每次迭代中处理的行数量(允许范围：100-100000)，默认值为1000。
-concurrent-rowcount:该参数如果为True(默认值)，则进行row-copy之后，估算统计行数(使用explain select count(*)方式)，并调整ETA时间，否则，gh-ost首先预估统计行数，然后开始row-copy。
-conf string:gh-ost的配置文件路径。
-critical-load string:一系列逗号分隔的status-name=values组成，当MySQL中status超过对应的values，gh-ost将会退出。-critical-load Threads_connected=20,Connections=1500，指的是当MySQL中的状态值Threads_connected>20,Connections>1500的时候，gh-ost将会由于该数据库严重负载而停止并退出。
-critical-load-hibernate-seconds int :负载达到critical-load时，gh-ost在指定的时间内进入休眠状态。 它不会读/写任何来自任何服务器的任何内容。
-critical-load-interval-millis int:当值为0时，当达到-critical-load，gh-ost立即退出。当值不为0时，当达到-critical-load，gh-ost会在-critical-load-interval-millis秒数后，再次进行检查，再次检查依旧达到-critical-load，gh-ost将会退出。
-cut-over string:选择cut-over类型:atomic/two-step，atomic(默认)类型的cut-over是github的算法，two-step采用的是facebook-OSC的算法。
-cut-over-exponential-backoff
-cut-over-lock-timeout-seconds int:gh-ost在cut-over阶段最大的锁等待时间，当锁超时时，gh-ost的cut-over将重试。(默认值：3)
-database string:数据库名称。
-default-retries int:各种操作在panick前重试次数。(默认为60)
-dml-batch-size int:在单个事务中应用DML事件的批量大小（范围1-100）（默认值为10）
-exact-rowcount:准确统计表行数(使用select count(*)的方式)，得到更准确的预估时间。
-execute:实际执行alter&migrate表，默认为noop，不执行，仅仅做测试并退出，如果想要ALTER TABLE语句真正落实到数据库中去，需要明确指定-execute
-exponential-backoff-max-interval int
-force-named-cut-over:如果为true，则'unpostpone | cut-over'交互式命令必须命名迁移的表
-heartbeat-interval-millis int:gh-ost心跳频率值，默认为500
-initially-drop-ghost-table:gh-ost操作之前，检查并删除已经存在的ghost表。该参数不建议使用，请手动处理原来存在的ghost表。默认不启用该参数，gh-ost直接退出操作。
-initially-drop-old-table:gh-ost操作之前，检查并删除已经存在的旧表。该参数不建议使用，请手动处理原来存在的ghost表。默认不启用该参数，gh-ost直接退出操作。
-initially-drop-socket-file:gh-ost强制删除已经存在的socket文件。该参数不建议使用，可能会删除一个正在运行的gh-ost程序，导致DDL失败。
-max-lag-millis int:主从复制最大延迟时间，当主从复制延迟时间超过该值后，gh-ost将采取节流(throttle)措施，默认值：1500s。
-max-load string:逗号分隔状态名称=阈值，如：'Threads_running=30,Threads_connected=500'. 表面如果在执行gh-ost的过程中出现Threads_running=30则暂停gh-ost的执行, Threads_running即活跃连接数 -migrate-on-replica:gh-ost的数据迁移(migrate)运行在从库上，而不是主库上。
-nice-ratio float:每次chunk时间段的休眠时间，范围[0.0…100.0]。0：每个chunk时间段不休眠，即一个chunk接着一个chunk执行；1：每row-copy 1毫秒，则另外休眠1毫秒；0.7：每row-copy 10毫秒，则另外休眠7毫秒。
-ok-to-drop-table: gh-ost操作结束后，删除旧表，默认状态是不删除旧表，会存在_tablename_del表。
-panic-flag-file string:当这个文件被创建，gh-ost将会立即退出。
-password string :MySQL密码
-port int ：MySQL端口，最好用从库
-postpone-cut-over-flag-file string：当这个文件存在的时候，gh-ost的cut-over阶段将会被推迟，数据仍然在复制，直到该文件被删除。
-skip-foreign-key-checks:确定你的表上没有外键时，设置为'true'，并且希望跳过gh-ost验证的时间-skip-renamed-columns ALTER
-switch-to-rbr:让gh-ost自动将从库的binlog_format转换为ROW格式。
-table string:表名
-throttle-additional-flag-file string:当该文件被创建后，gh-ost操作立即停止。该参数可以用在多个gh-ost同时操作的时候，创建一个文件，让所有的gh-ost操作停止，或者删除这个文件，让所有的gh-ost操作恢复。
-throttle-control-replicas string:列出所有需要被检查主从复制延迟的从库。
-throttle-flag-file string:当该文件被创建后，gh-ost操作立即停止。该参数适合控制单个gh-ost操作。-throttle-additional-flag-file string适合控制多个gh-ost操作。
-throttle-query string:节流查询。每秒钟执行一次。当返回值=0时不需要节流，当返回值>0时，需要执行节流操作。该查询会在数据迁移(migrated)服务器上操作，所以请确保该查询是轻量级的。
-timestamp-old-table:在旧表名中使用时间戳。这会使旧表名称具有唯一且无冲突的交叉迁移。
-user string :MYSQL用户
使用
下载安装
在github release页面下载
https://github.com/github/gh-ost/releases/download/v1.1.0/gh-ost-1.1.0-1.x86_64.rpm
上传到服务器,安装
yum install gh-ost-1.1.0-1.x86_64.rpm
执行变更
示例：
自建MySQL
gh-ost --user="xxxx" --password="xxxx" --host=localhost --database="guo_test" --table="a" --alter="ADD COLUMN bcbde INT" --execute --max-load=Threads_running=30 --critical-load=Threads_running=50 --critical-load-interval-millis=5000 --chunk-size=1000 --heartbeat-interval-millis=2000 --ok-to-drop-table --assume-rbr --allow-on-master 2>&1 | tee /tmp/rebuild_t1.log
阿里云RDS
gh-ost --user="xxxx" --password="xxxx" --aliyun-rds --host='xxxx' --port=3306 --assume-master-host="xxxx:3306" --database="guo_test" --table="sbtest" --alter="add COLUMN aa int " --execute --max-load=Threads_running=30 --critical-load=Threads_running=50 --critical-load-interval-millis=5000 --chunk-size=1000 --heartbeat-interval-millis=2000 --ok-to-drop-table --throttle-additional-flag-file=/tmp/gh-ost.throttle --panic-flag-file=/tmp/ghost.panic.flag --assume-rbr --allow-on-master --aliyun-rds --execute 2>&1 | tee /tmp/rebuild_t1.log
推荐使用参数：
--assume-rbr
--max-load=Threads_running=30
--critical-load=Threads_running=50
--critical-load-interval-millis=5000
--chunk-size=1000
--heartbeat-interval-millis=2000
--throttle-additional-flag-file=/tmp/gh-ost.throttle
--panic-flag-file=/tmp/ghost.panic.flag
测试限流可以使用,也可以通过删除/tmp/ghost.postpone.flag文件控制cut-over时机
--postpone-cut-over-flag-file=/tmp/ghost.postpone.flag
上面参数具体数值，根据服务器实际压力情况修改
阿里云RDS需添加如下参数：
–allow-on-master
–assume-rbr
–assume-master-host
–aliyun-rds
特别说明:
针对几百G的大表做归档删除数据之后要重建表，以便减少表空间大小。重建完，进行cut-over切换幽灵表和原表时，默认不删除幽灵表。因为直接删除上百 G 会对磁盘 IO 有一定的影响.
根据自己的情况去调整合适的参数，注意以下两个参数。
--ok-to-drop-table:gh-ost操作结束后，删除旧表，默认状态是不删除旧表，会存在_tablename_del表。
--timestamp-old-table 最终rename的时候表名会加上时间戳后缀，每次执行的时候都会生成一个新的表名。
错误忽略
执行过程中会报一个error，日志如下：
Copy: 1/1 100.0%; Applied: 0; Backlog: 0/1000; Time: 3s(total), 1s(copy); streamer: binlog.000003:118844; Lag: 0.01s, State: migrating; ETA: due
[2020/09/27 16:49:00] [info] binlogsyncer.go:164 syncer is closing...
[2020/09/27 16:49:01] [error] binlogstreamer.go:77 close sync with err: sync is been closing...
[2020/09/27 16:49:01] [info] binlogsyncer.go:179 syncer is closed
# Done
[error] binlogstreamer.go:77 close sync with err: sync is been closing…
对应issue：
https://github.com/github/gh-ost/issues/749
开发者shlomi-noach的回复是
Sorry for the late response. Yes, this has been reported multiple times; this is an error message from an underlying library that connects to MySQL; however, there is no gh-ost error here, as gh-ost retries connection/operation as needed. It is unfortunate that the log contains all these messages but I can’t control it.
大意为：
这是来自连接到MySQL的基础库的错误消息；没有gh-ost错误，目前无法控制
暂停 / 恢复
我们可以通过创建 / 删除 throttle-additional-flag-file 指定的文件 /tmp/gh-ost.throttle 控制 gh-ost 对 binlog 应用.
限流
gh-ost 可以通过 unix socket 文件或者 TCP 端口（可配置）的方式来监听请求，DBA 可以在命令运行后更改相应的参数，参考下面的例子：
打开限流
echo throttle | nc -U /tmp/gh-ost.guo_test.sbtest.sock
如果没有nc，需要先安装nc，gh-ost.guo_test.sbtest.sock格式为，gh-ost.db_name.table_name.sock。
_tablename_ghc 中会多一条记录
287 2020-09-27 11:18:54 throttle at 1601263134871924413 commanded by user
关闭限流
no-throttle | socat - /tmp/gh-ost.test.b.sock
_tablename_ghc 中会多一条记录
348 2020-09-27 11:22:06 throttle at 1601263326077186389 done throttling
改变执行参数: chunk-size=1024, max-lag-millis=100, echo max-load=”Threads_running=30” critical-load=”Threads_running=50” 这些参数都可以在运行时动态调整。
echo chunk-size=1024 | nc -U /tmp/gh-ost.guo_test.sbtest.sock
echo max-lag-millis=100 | nc -U /tmp/gh-ost.guo_test.sbtest.sock
echo max-load="Threads_running=30" | nc -U /tmp/gh-ost.guo_test.sbtest.sock
echo critical-load="Threads_running=50" | nc -U /tmp/gh-ost.guo_test.sbtest.sock
终止运行
我们通过来过创建 panic-flag-file 指定的文件，立即终止正在执行的 gh-ostmin
创建文件 /tmp/ghost.panic.flag
touch /tmp/ghost.panic.flag
gh-ost log 提示
2019-08-31 22:50:52.701 FATAL Found panic-file /tmp/ghost.panic.flag. Aborting without cleanup
四 与 pt-osc 的对比
从功能，稳定性和性能上来看，两种工具各有千秋，虽然在高并发写的情况下，gh-ost 应用 binlog 会出现性能较低不如 pt-osc 的情况。不过 gh-ost 更灵活，支持我们根据实际情况动态调整。
推荐阅读：
初试GH-OST
GitHub开源的MySQL在线更改Schema工具
MySQL · 社区动态 · Online DDL 工具 gh-ost 支持阿里云 RDS
